home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1997 February / EnigmA AMIGA RUN 15 (1997)(G.R. Edizioni)(IT)[!][issue 1997-02][PLANET CD V].iso / progs / editor / frexxed / fpl / rcscontrol.fpl.readme < prev    next >
Text File  |  1996-04-01  |  8KB  |  163 lines
  1. #############################################################################
  2. File:        RCSControl
  3. Author:        Jesper Skov
  4. Email:        jskov@iesd.auc.dk
  5. Short:        Easy RCS control from FrexxEd
  6. Version:    1.5
  7. Date:        01.01.96
  8. Local settings:
  9. Global settings:
  10. Keysequence:    'C-x C-q' and 'C-x C-Q'
  11. Type:        function
  12. Prereq:
  13. Copyright:    © 1994-1996, Jesper Skov
  14. #############################################################################
  15.  
  16. PREFACE
  17.   RCS is a nice thing, but I have experienced a few situations where I was
  18.   not 100% sure that this interface did its job properly. A couple of times I
  19.   even had to "rescue" a file by hand. This was not *acceptable*! Therefore
  20.   this update which checks the result of the RCS calls.
  21.  
  22.  
  23. FUNCTION
  24.   This RCS control interface will give you a very easy way of bumping and
  25.   describing your code/text revisions.
  26.   The backbone of this control is the possibility of write protecting a
  27.   buffer, which (by ways of incredible luck :) is provided by
  28.   FrexxEd. With this write protection (wp) it is _very_ simple for
  29.   you to see if you have "control" over a given buffer - you will not be
  30.   able to change the buffer if not. Now you may wonder what wp has to do with
  31.   revision control... Um, very good question actually. I guess the answer is
  32.   >nothing< :) Oh well, maybe a little; on UN*X machines (multi user
  33.   environment) where (many) different people may work with the same files, it
  34.   is often desirable to lock out other users while a file is changed. To
  35.   control this "who's-changing-what-and-when" problem some smart guys invented
  36.   'revision control systems', which also keep track of changes and history.
  37.   Now, such a system has been ported to the Amiga and why not use what is at
  38.   hand? I know that there exist "history control systems" and RC systems
  39.   written for the Amiga, but I just happen to know this system from school:
  40.   GNU RCS. The Amiga port is done by Heinz Wrobel and is called `HWGRCS'.
  41.   You can find the archive on AmiNet (and Fish, I guess) where it is called
  42.   `HWGRCSp?f.lha'. The '?' indicates the latest patch level number (I use
  43.   level 10). You will have to put the RCS files in a directory accessible
  44.   with the assign "bin:" (e.g. copy them to C: and assign bin: to C:).
  45.  
  46.   Wow, lotsa text about nothing... Still with me? OK, operation:
  47.   First time invoked on a (non-wp) file: You will be asked if the file should
  48.   be put under RCS control.
  49.     -- NO : buffer will be writeprotected.
  50.     -- YES: You will be asked if an RCS directory should be created if not
  51.             already there (this will keep your directory tiddier :)
  52.             Then you will be told (or reminded, whatever) that the first
  53.             comment entry is used for file description.
  54.   2nd+ time invoked (non-wp):
  55.     A comment buffer will be opened where you may enter revision specific
  56.     information. Only when you press C-c C-c will the revision update take
  57.     effect, in which case the file is locked (checked in) and the buffer is
  58.     write protected (the comment buffer disappears). You may explicit cancel
  59.     the locking by pressing C-g, which will kill the comment buffer.
  60.   If invoked on a write protected buffer, the buffer is made changeable
  61.   (de-wp'ed =) and if the file is under RCS control it will be unlocked,
  62.   checked out (see TO DO).
  63.  
  64.   You can also use the sequence C-x C-Q which will do a normal check in,
  65.   followed immediately by a check out. Use this to bump the revision when
  66.   you want to continue editing.
  67.  
  68.   If you want to use this system you should also have a good long look at
  69.   the RCS documentation (and perhaps one at my code so you know what's
  70.   going on :)
  71.  
  72.   Invoke the function RCSMakeHistory to extract a file's history. The output
  73.   is by default redirected to filename.history.
  74.  
  75.  
  76.   As of version 1.4 the result of the check in and check out operations is
  77.   checked. 
  78.  
  79.   Check out failure
  80.   ~~~~~~~~~~~~~~~~~  
  81.   If a check out failed, it is most likely because there was already a lock
  82.   on the file. The easy way to get around this is to force a check out (you
  83.   will be given this option), but this may also be dangerous if the locked
  84.   file has been changed. If there has not been any hiccup in the check in/out
  85.   cycle prior to this point, you would probably have the changed file in
  86.   FrexxEd (i.e. it's OK to force a check out). On the other hand; if you are
  87.   not sure, you should definitely do some checking by hand (i.e. compare the
  88.   file with what RCS claim to be the latest revision - consult the RCS
  89.   documentation).
  90.  
  91.   Check in failure
  92.   ~~~~~~~~~~~~~~~~
  93.   Maybe you forgot to check out and changed the write protection flag by
  94.   hand. Or another program did it. Or..? You will be asked if the file should
  95.   be checked out before saving the buffer and checking in again. This should
  96.   be perfectly safe to do. If you choose not to do this, remember that the
  97.   changes you made were not registered with RCS.
  98.  
  99.  
  100.   As of version 1.5 you may now control the RCS interface via a sub menu of
  101.   "Project":
  102.  
  103.   Check Out/In:    For those who can't seem to remeber good old C-x C-q.
  104.   Rename:    You will be asked for the new name. The reason for using this
  105.         specific RCS function and not just rename is that this
  106.         function also renames the RCS file.
  107.   Locked files:    This function will prompt you for a path and then scan it for
  108.         locked RCS files, presenting the result in a buffer. If you
  109.         start a scan high in a directory structure, it may take some
  110.         time to complete.
  111.   History:    Will extract the RCS log of the current file and clean it a up
  112.         a bit. The log will then be presented in a buffer.
  113.   Extract time:    Will extract the RCS log of the current file and strip out
  114.         everything but the time logs (see below). These are added up
  115.         and the    result is presented in a buffer.
  116.  
  117.   Since I have needed a handy way of keeping track of the time spend on
  118.   various projects, and don't think much of the tools available for this
  119.   task, I figured it was about time to add a little extra to this RCS
  120.   interface. The result is time tracker which is based on the "check
  121.   out"-"check in" cycle, thus adding another good reason for using RCS.
  122.   However, since RCS does not log the time of check out I've had to use the
  123.   file's comment field for this information.
  124.  
  125.   You may control if the co/ci cycles should be timed by the variable
  126.   "RCStimeWork" in Globals->IO.
  127.  
  128.   If you wan't to use this new feature effectively for calculating project
  129.   time, you'll have to be careful about *always* checking in when you're done
  130.   working (I usually forget to check in a few files during a week). For the
  131.   same reason, the Lock list comes in handy.
  132.  
  133.  
  134. TO DO
  135.  Check out specific revision.
  136.  Re-check out this revision (thus cancelling work)
  137.  Warning at exit if any files are still checked out (possibly auto-ci).
  138.  
  139. HISTORY (REV)
  140.  01.01.96 (5)    Added menu.
  141.          Added time log (I just *love* this one!)
  142.         Added lock list.
  143.         Added Rename.
  144.  04.10.95 (4)    Made the check in/out a bit safer.
  145.  26.02.95 (3)    Check in speed up (see bugs).
  146.         Code cleaned up.
  147.  05.02.95 (2)    Problems with FrexxEd's writeprotection fixed.
  148.  26.10.94 (1)    Added the RCSMakeHistory function.
  149.  25.10.94 (0)    Initial revision.
  150.  
  151. BUGS
  152.  When you bump a file (C-x C-Q) FrexxEd will complaint (when you try to save
  153.  it again) that the file has been changed on disk. This is because check in
  154.  is now done without re-loading the file (speed up). You'll have to do a
  155.  "manual override" for now... I'll have a chat with Daniel about a proper
  156.  solution =)
  157.  
  158.  Other bug reports to my EMail address, thanks.
  159.  
  160. SEE ALSO
  161.  RCS documentation (not included)
  162.  Michael Crichton's "Congo" (ISBN:0-14-00-5863-X)
  163.